Setting Values during Installation

Helm chart default values#

Most Helm charts can be installed with a simple command in which we only specify the name of a chart and a release. But what if it’s not enough and we need to have a different version of an application than the latest? Or if our incoming traffic is so heavy that we require two or more instances of the same application?

Luckily, there is a solution to this and other similar problems: the values.yaml file. Each Helm chart should have it. It plays the role of a chart’s interface that is used to interact with it. It’s essentially a YAML file that contains several properties which we can change to tweak a Helm release. All of them are declared in the file with the default values.

By reading it we can find out that the resulting container is based on kubernetesui/dashboard and the version v2.4.0. Moreover, default instances, i.e., replicas, are declared with a replicaCount property (here it is 1).

If we don’t use a chart that’s on Artifact Hub, values.yaml can be found in the root folder of a chart, like it is in the GitHub repository of the Kubernetes Dashboard, as shown below:

Right now we would encourage you to stop reading this for a moment and examine this file for the Dashboard Helm chart. Try to figure out what is the purpose of each declared property. Most of them have comments that explain their purpose and make it easier to understand. But don’t worry if they are not clear yet.

Once you’re done with that, we can start to override some of the declared properties.

Upgrade the Helm release#

Helm CLI offers two ways of overriding default values from the values.yaml file:

• By using the --values/-f flag and providing a path to a YAML file in which one or multiple properties are overridden

• By providing the --set flag and passing the key-value pair of properties directly in a command line

Let’s examine each method and find out which one is better in what circumstances. As an example, we’ll change a Docker image tag and a version of a resulting container.

Install with a YAML file#

In the first approach, we will need to create a YAML file, which we’ll call dashboard.yaml, as follows:

With this simple file, we’ll tell Helm that it needs to override the image.tag property declared in the values.yaml file from v2.4.0 to v2.0.0. All other default properties will remain untouched.

The most important thing to note is that the property structure in the dashboard.yaml file is the same as the one declared in the values.yaml file from the Helm chart. If we make a slight mistake with an indentation or by misspelling the property, Helm will not understand it and won’t override it.

In this file we can install Dashboard (but please don’t do that yet) by running a command, as shown below:

The --values dashboard.yaml part at the end of the command indicates a path to a file that contains values to be overridden.

Tip: Instead of a lengthy --values flag we can use the shorter -f flag.

The helm install command can be used only once during the initial installation. If we try it for a second time, we’ll get an error.

Install with the --set flag#

For those who don’t like to create many files or are especially averse to YAML files, there is another approach: We can pass values that need to be overridden with the --set flag.

Execute the following command to install the Kubernetes Dashboard:

To test both of the installation commands (one with --set; the second with --values), make sure that release names are different for both of them.

There is a drawback to this solution. If we need to override multiple values we would add as many --set flags as properties. That’s why it’s usually better to apply new values using the YAML file.

Another advantage of the --values approach is that we can put the entire configuration of our cluster into a set of files. Each application could have an easy-to-understand YAML config file that can be put into the version control system (e.g., Git) and track what changes were made and by whom. This is an approach that is very popular in large companies where many developers deploy their applications to shared clusters, and it’s a foundation for GitOps.

Finally, if we have a configuration as a file it’s easier to recreate or duplicate an entire cluster in case of an emergency or if we want to duplicate it somewhere else. The only thing that is needed is to run the same command but against a different cluster, and Helm will do all the work for us.

For these reasons, it’s encouraged to use a YAML file. There are some specific situations when --set is the only option (e.g., when an overridden value is set up dynamically on a CI/CD pipeline), but try to limit them as much as possible.

Now, let’s practice what we have learned.